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BACKGROUND OF THE INVENTION 

1. The Field of the Invention 

[0001] The present invention relates to accessing schematized contact data. More 
specifically, the present invention relates to utilizing contact data controls to simply access 
to schematized contact data. 

2. Background and Relevant Art 

[0002] As the computer industry continues to develop new and efficient means for 
communicating with contacts are becoming a reality. It is now commonplace, for example, 
for people to use their personal computers to communicate via e-mail, facsimile, instant 
message (IM), telephony, video teleconference (VTC), and so forth. This development of 
enabled communication through computerized devices has greatly enhanced the need for 
applications to store the contact information that is required for enabling communication and 
corroboration between contacts. 

[0003] Contact information is generally referred to herein as information that can be 
considered relevant for contacting, accessing, corresponding with or otherwise 
communicating with a contact. Contact information may include, for example, the names, 
aliases, telephone numbers, e-mail addresses, IM addresses, home addresses, and web 
addresses of a contact. Contact information can also refer to other types of information such 
as a real time status, location or disposition of a contact. For example, information 
indicating a contact is currently connected to a network or on a telephone line may also be 
broadly construed as contact information. 
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Because there are so many different types of contact information, it can be difficult for 
anyone to remember all of the contact information that is associated with the various 
contacts that they communicate with. The difficulty in remembering contact information is 
even further magnified by the fact that different applications require different types of 
contact information and sometimes different formats of contact information. 
[0004] Accordingly, many applications are configured to store this information so that 
users do not have to commit it to memory. For example, e-mail applications typically utilize 
directories that are configured for storing the e-mail addresses of contacts that can be e- 
mailed. Likewise, telephony applications typically utilize directories for storing telephone 
numbers of contacts that can be called telephonically. Other examples of applications that 
store contact information include time management applications, instant messaging 
applications, network gaming applications, business directory applications, VTC 
applications, and so forth. 

[0005] In order for a user to obtain the contact information that will be used by a 
particular application, such as, for example, to initiate a communication or to fill out a form, 
a user can query a contact information directory that is associated with the application. 
Accessing a contact information directory, however, is somewhat undesirable because it can 
increases the total amount of time that is required of the user. Even when the contact 
information is already known, the delay in time it takes to manually enter the known contact 
information can also be undesirable. 

[0006] Contact information directories are typically configured to store only limited 
amounts of relevant information. For example, some contact information directories are 
configured to store only contact information specifically required by a corresponding 
application (e.g., a contact information directory associated with a telephony application 
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may be configured to only store the telephone numbers and not e-mail addresses). Limiting 
the amount of contact information in a contact information directory can reduce the 
complexity of a corresponding interface, resulting in efficient access to contact information 
that is relevant at a particular time. For example, a telephony interface can provide simply 
and efficient access to telephone numbers. 

[0007] The use of contact directories also extends to devices that are not considered 
traditional computers. For example, many telephones, facsimile devices, and photocopying 
devices also include contact directories for storing contact information that may be used to 
perform a desired function such as initiating a telephone call, a facsimile transmission, or a 
telecopy transmission. 

[0008] Despite the benefits provided by existing contact management systems, the large 
variety of specialized and disparate contact information directories that are associated with 
the various applications and devices can make it difficult for users to quickly access all of 
the available contact information that corresponds to a particular contact. This is 
particularly true when considering that some of the disparate contact management 
directories contain different contact information. 

[0009] One reason disparate contact information directories are problematic is that use 
of disparate contact information directories can increase the difficulty of identifying all 
available means for communicating with a contact. That is, a user desiring to access contact 
information may be required to separately access a number of different contact information 
directories (through a number of different interfaces) to obtain all the desired contact 
information. For example, it may be necessary to access a telephone directory to obtain the 
home or cell telephone number for the contact, an e-mail directory to obtain a primary e- 
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mail address for the contact, a business directory to obtain the business telephone number, 
and business e-mail address of the entity, and so forth. 

[0010] Having disparate contact information directories can also be problematic for 
obtaining different types of contact information about different contacts. For example, it 
may be desirable to view the e-mail address of a first contact, the business telephone number 
of a second contact, and the cell telephone number of a third contact. If the desired contact 
data for each of the different entities is located in a different contact management system of 
different applications, then each application will have to be accessed to obtain the desired 
information, thereby requiring the undesirable expenditure of time and resources. 
[0011] Searches and queries for specific contacts or contact information must also be 
performed separately through corresponding interfaces for accessing each of the various 
contact directories. It will be appreciated that this can be particularly problematic when a 
user has forgotten in which of the contact directories the contact information is stored. 
[0012] To overcome some of these problems, some contact management systems are 
configured to redundantly store contact information that is not necessarily required for use 
by the corresponding application. For example, an e-mail directory may be configured to 
store the addresses, phone numbers and other information about the various contacts, even 
though this information is not required to enable e-mail communications. 
[0013] The variety of directories and corresponding storage capabilities, however, can 
vary from one application to the next, thereby increasing the difficulty for users to know 
which of the contact information can be duplicated in each of the different directories. 
Furthermore, even when it is possible for portions of the contact information to be 
redundantly stored in each of the different contact directories, such redundant storage would 
represent undesirable and unnecessary expenditure of computing resources. 
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[0014] Yet another problem with redundantly storing contact information within existing 
contact directories is that it can be difficult to propagate changes to the contact information 
throughout all of the various contact directories that are storing the modified contact 
information. In particular, the separate storage of the contact information in each of the 
directories necessitates that the change to the contact information be entered into each of the 
directories. Otherwise, the contact information that is available will be inconsistent and 
possibly incorrect. 

[0015] Another problem with existing contact management systems is that because they 
are so specialized, they fail to provide very extensive and rich search and view capabilities 
of the contact information. In particular, most contact management systems are relegated to 
providing only two-dimensional columns or lists of the stored data. Yet another problem 
with existing contact management systems is that they do not enable a user to view, create, 
and edit relationships between contacts. More particularly, existing systems do not enable a 
user to view the relationships existing between contacts or to create and edit these 
relationships. 

[0016] Accordingly, some mechanisms for utilizing a common concept of a contact 
across a number of applications have been developed. Contacts are created and stored with 
corresponding contact information in such a way that they can be accessed and utilized from 
a single contact store. For example, contact information can be stored according to a 
common contact schema that is accessible to applications that store and retrieve the contact 
information. Applications can be heterogeneous applications that utilize different portions 
of the contact information or utilize the same contact information in a different ways. 
[0017] However, due at least in part to the sheer number of different data types and 
different data formats that may expressed in a common contact schema, it may be difficult 
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for applications to access contact information according to the common contact schema. 
Further, application designers may have difficulty understanding a common contact schema 
and designing applications that insure compliance with the common contact schema during 
execution. Unfortunately, non-compliance with data types and/or data formats expressed in 
a common contact schema can make corresponding contact information unstorable or 
inaccessible or may even cause the centralized location to malfunction. Malfunction of the 
centralized location may prevent a number of other applications from accessing contact 
information. Accordingly, what would be advantageous are mechanisms for simplifying 
access to schematized contact information. 
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BRIEF SUMMARY OF THE INVENTION 
[0018] The present invention is directed to methods, systems, and corresponding 
computer program products for utilizing contact data controls to simplify access to 
schematized contact data. A user-interface contact data control can provide an application 
with user-interface data that can be presented to a user. The application can access the user- 
interface data to present a user-interface to the user. In some embodiments, an application 
that lacks the configuration to natively access schematized contact data (e.g., due to an 
inability to translate contact data or due to not being authorized) receives a request to access 
schematized contact data. It may be that the request is received at a contact data control 
provided user-interface. The application forwards the request to a data interface contact 
data control that abstracts the formatting of the schematized contact data from the 
application. 

[0019] The data interface contact data control receives the forwarded request and 
retrieves schematized contact data in response to the request. The data interface contact data 
control converts retrieved schematized contact data to corresponding non-schematized 
contact data such that the application can present contact data. The data interface contact 
data control sends the non-schematized contact data to the application. A user-interface data 
control can provide the application with user-interface data for presenting the non- 
schematized data to the user. The application presents the non-schematized contact data. 
[0020] In other embodiments, an application that lacks the configuration to natively 
update schematized contact data receives non-schematized contact data (e.g., through a user- 
interface provided by a user-interface contact data control) that is to be used to update 
schematized contact data. The application forwards the non-schematized contact data to a 
data interface contact data control that abstracts the formatting of the schematized contact 
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data from the application. The schematized contact data is updated based on the non- 
schematized contact data. 

[0021] The data interface contact data control receives the non-schematized contact data 
and converts the non-schematized contact data to corresponding schematized contact data 
that conforms to a contact data schema. The data interface contact data control stores 
corresponding schematized contact data such that other applications can access the stored 
schematized contact data (e.g., in accordance with the contact data schema). It may be that a 
contact data control includes the functionality of both a user-interface contact data control 
and data interface contact data control. 

[0022] Additional features and advantages of the invention will be set forth in the 
description which follows, and in part will be obvious from the description, or may be 
learned by the practice of the invention. The features and advantages of the invention may 
be realized and obtained by means of the instruments and combinations particularly pointed 
out in the appended claims. These and other features of the present invention will become 
more fully apparent from the following description and appended claims, or may be learned 
by the practice of the invention as set forth hereinafter. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0023] In order to describe the manner in which the above-recited and other advantages 
and features of the invention can be obtained, a more particular description of the invention 
briefly described above will be rendered by reference to specific embodiments thereof which 
are illustrated in the appended drawings. Understanding that these drawings depict only 
typical embodiments of the invention and are not therefore to be considered to be limiting of 
its scope, the invention will be described and explained with additional specificity and detail 
through the use of the accompanying drawings in which: 

[0024] Figure 1 illustrates an example of a computer architecture that facilitates 
simplified application access to schematized contact data. 

[0025] Figure 2 illustrates an example flowchart of a method for simplifying application 
access to schematized contact data. 

[0026] Figure 3 illustrates an example flowchart of a method for simplifying application 
updates to schematized contact data. 

[0027] Figure 4A illustrates a first example of a contact data control user-interface. 
[0028] Figure 4B illustrates a second example of a contact data control user-interface. 
[0029] Figure 4C illustrates a third example of a contact data control user-interface. 
[0030] Figure 4D illustrates a fourth example of a contact data control user-interface. 
[0031] Figure 5 illustrates a suitable operating environment for the principles of the 
present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



[0032] The present invention is directed to methods, systems, and corresponding 
computer program products for utilizing contact data controls to simplify access to 
schematized contact data. 

[0033] In this description and in the following claims, a "network" is defined as one or 
more data links that enable the transport of electronic data between computer systems and/or 
modules. When information is transferred or provided over a network or another 
communications connection (either hardwired, wireless, or a combination of hardwired or 
wireless) to a computer system, the connection is properly viewed as a computer-readable 
medium. Thus, any such connection is properly termed a computer-readable medium. 
Combinations of the above should also be included within the scope of computer-readable 
media. Computer-executable instructions comprise, for example, instructions and data 
which cause a general-purpose computer system or special-purpose computer system to 
perform a certain function or group of functions. The computer executable instructions may 
be, for example, binaries, intermediate format instructions such as assembly language, or 
even source code. 

[0034] In this description and in the following claims, a "computer system" is defined as 
one or more software modules, one or more hardware modules, or combinations thereof, that 
work together to perform operations on electronic data. For example, the definition of 
computer system includes the hardware components of a personal computer, as well as 
software modules, such as the operating system of the personal computer. The physical 
layout of the modules is not important. A computer system may include one or more 
computers coupled via a network. Likewise, a computer system may include a single 
physical device (such as a mobile phone or Personal Digital Assistant "PDA") where 
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internal modules (such as a memory and processor) work together to perform operations on 
electronic data. 

[0035] In this description and in the following claims, a "schema" is defined as an 
expression of a shared vocabulary that allows different components to process data 
according to the expressed shared vocabulary. A schema can define and describe a class of 
data using schema constructs (e.g., name/value pairs) of schema language. These schema 
constructs can be used to constrain and document the meaning, usage, and relationships of 
data types, elements and their content, attributes and their values, entities and their contents, 
and notations. A schema can be utilized to define virtually any data type including logical, 
binary, octal, decimal, hexadecimal, integer, floating-point, character, character string, user- 
defined data types, and combinations of these data types used to defined data structures. 
Some examples of user-defined data types are DateTime data types representing date and 
time data and EAddress data types representing electronic addresses data, such as, for 
example, telephone numbers, electronic mail address, instant message addresses, etc. 
[0036] As defined herein, the term "contact" generally refers to any person, group, 
organization, business, or other type of identifiable entity. The term contact can also include 
or imply an interaction, connection, relationship or association, between two or more 
entities. As stored in a centralized data store, the contact can include one or more data 
structures having fields that define or otherwise include the contact data corresponding to a 
particular contact. 

[0037] The term "contact data," as used herein, and which is defined above in more 
detail, generally includes information that corresponds to a contact and that may be 
considered relevant for identifying, contacting, accessing, corresponding or communicating 
with the contact. Contact data can also be defined as any information corresponding to a 
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person. At certain times, herein, the term contact data and contact are used interchangeably, 
inasmuch as the term can be construed to broadly encompass the corresponding contact data. 
Contact data defined in accordance with a schema can be viewed as "schematized contact 
data". 

[0038] In various embodiments described herein, interfaces are used to control 
association of and access to contacts and corresponding contact data. These interfaces can 
be created, modified and used through computer software components, such as, for example, 
computer-executable instructions or computing modules. 

[0039] As described herein, a programming interface (or more simply, an interface) may 
be viewed as any mechanism, process, protocol for enabling one or more segment(s) of code 
to communicate with or access the functionality provided by one or more other segment(s) 
of code, such as, for example, to access contact data. Alternatively, a programming 
interface may be viewed as one or more mechanism(s), method(s), function call(s), 
module(s), object(s), etc. of a component of a system capable of communicative coupling to 
one or more mechanism(s), method(s), function call(s), module(s), etc. of other 
component(s). The term "segment of code" in the preceding sentence is intended to include 
one or more instructions or lines of code, and includes, e.g., code modules, objects, 
subroutines, functions, and so on, regardless of the terminology applied or whether the code 
segments are separately compiled, or whether the code segments are provided as source, 
intermediate, or object code, whether the code segments are utilized in a runtime system or 
process, or whether they are located on the same or different machines or distributed across 
multiple machines, or whether the functionality represented by the segments of code are 
implemented wholly in software, wholly in hardware, or a combination of hardware and 
software. 

- Page 13 - Docket No. 13768.495 



[0040] Accordingly, it will be appreciated that the embodiments of the invention can 
include special purpose and general-purpose computing devices including various computer 
software and hardware that can be used to enable the interfaces described herein. The 
embodiments within the scope of the present invention can also include computer-readable 
media for carrying or having the computer-executable instructions or data structures stored 
thereon that comprise the interfaces and the code for using and modifying them. 
[0041] It will be appreciated that the computer-readable media can be any available 
media that can be accessed by a general purpose or special purpose computer, including, but 
not limited to mobile communications devices. By way of example, and not limitation, such 
computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical 
disk storage, magnetic disk storage or other magnetic storage devices, or any other medium 
which can be used to carry or store desired program code means in the form of computer- 
executable instructions or data structures and which can be accessed by a general purpose or 
special purpose computer. The computer-executable instructions comprise, for example, 
instructions and data which cause a general purpose computer, special purpose computer, or 
special purpose processing device to perform a certain function or group of functions, such 
as the acts and steps described below. 

[0042] When information is transferred or provided over a network or another 
communications connection (either hardwired, wireless, or a combination of hardwired or 
wireless) to a computer or mobile communications device, the computer/device properly 
views the connection as a computer-readable medium. Thus, any such connection is 
properly termed a computer-readable medium. Combinations of the above should also be 
included within the scope of computer-readable media. 
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[0043] Those skilled in the art will appreciate that the invention may be practiced in 
network computing environments with many types of computer system configurations, 
including, personal computers, laptop computers, hand-held devices, multi-processor 
systems, microprocessor-based or programmable consumer electronics, network PCs, 
minicomputers, mainframe computers, mobile telephones, PDAs, pagers, or other smart 
mobile devices. The invention may also be practiced in distributed system environments 
where local and remote computer systems, which are linked (either by hardwired data links, 
wireless data links, or by a combination of hardwired and wireless data links) through a 
network, both perform tasks. In a distributed system environment, program modules may be 
located in both local and remote memory storage devices. 

[0044] Figure 1 illustrates an example of a computer architecture 100 that facilitates 
simplified application access to schematized contact data. According to various methods 
and systems described herein, schematized contact data 108 can be stored in a centralized 
contact store. Although a centralized contact store can comprise a single computer readable 
media, it will be appreciated that in some embodiments, a centralized contact store actually 
comprises a plurality of computer-readable media, such that the centralized contact store is 
centralized only in theory and by way of functionality. 

[0045] The centralized contact store preferably includes a complete definition of a 
contact, including all of the corresponding contact data that is required by the various 
applications that access the contact. In some embodiments, however, the definition of the 
contact is only partially complete, but still able to satisfy the information requirements of the 
various applications that access the contact data. 

[0046] Within computing system 101, various applications 102, 103, 104 are shown that 
can attempt to access and/or update schematized contact data 108. Access or updates to 
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schematized contact data 108 can occur directly or indirectly. Where direct communication 
can provide quick and unfettered access to the entire contact store, indirect communication 
such as through interfaces can provide more control and security. Various contact data 
controls 106, 107 are also shown. Contact data controls can abstract the formatting of 
schematized contact data 108 from applications. Accordingly, applications that lack the 
configuration to access or update schematized contact data 108 directly may instead access 
schematized contact data 108 indirectly by calling a contact data control. 
[0047] It may be that an application lacks the configuration to natively access 
schematized contact data. For example, an application may lack the functionality to 
translate between schematized and non-schematized contact data. Further, it may also be 
that an application is not authorized to access schematized contact data (e.g., stored in 
schematized contact data 108). Accordingly, an application can invoke the functionality of a 
contact data control to provide translation between schematized and non-schematized 
contact data and /or to provide authorization to access schematized contact data. 
[0048] Contact data controls can implement a wide variety of functionality. Some data 
controls provide user-interface data that can be accessed by an application to present a user- 
interface (hereinafter referred to as "user-interface contact data controls"). Other data 
controls can accesses schematized contact data and/or translate between schematized and 
non-schematized contact data (hereinafter referred to as "data interface contact data 
controls"). Yet other data controls can provide combined functionality of both a user- 
interface contact data control and a data interface contact data control (hereinafter referred to 
as "combined contact data controls"). 

[0049] It will be appreciated that the illustrated applications 102, 103, 104, contact data 
controls 106 and 107, and schematized contact data 108 can be hosted by the same 
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computing device, or by one or more remote computing devices. Whether hosted by the 
same or different computing devices, contact data controls can be external to an application 
that calls the contact data control Contact data controls can have appropriate APIs for 
interfacing with calling applications. 

[0050] As described herein, the applications 102, 103, 104 may attempt access or update 
schematized contact data 108 (either directly or indirectly) for various reasons, such as to 
provide, obtain, modify, or otherwise utilize contact data. The applications 102, 103, 104 
can include any type of application, including, but not limited to e-mail applications, 
telephone and telephony applications, time management applications, instant messaging 
applications, gaming applications, business directory applications, VTC applications, RTC 
applications, instant messaging applications, facsimile applications, and so forth. Thus, it 
may be that contact data controls provide portions of the functionality of these and other 
applications. 

[0051] Following are some examples of the functionality that can be implemented in a 
contact data control. For example, a contact data control can cause an application not to 
present schematized data fields with NULL values. For example, if schematized contact 
data representing a contact has six fields formatted for storing telephone numbers but only 
three of the fields contain telephone numbers, a contact data control may suppress the three 
empty fields (e.g., represented by a NULL value) from being presented at an application. 
Accordingly, the contact control data presented at an application can be simplified. 
[0052] A contact data control can offer an actionable editing user-interface. For 
example, a contact data control can associate presented and editable contact data with one or 
more verbs. Verbs can be selected (e.g., in response to user-input) from the actionable 
editing user-interface to perform an action. For example, selecting a field containing a 
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telephone number can cause a dialer to dial the telephone number, selecting a field 
containing an e-mail address can cause an e-mail program to execute, selecting a field 
containing a birth date can cause a birthday card to be sent, etc. Verbs can cause other data 
repositories to be read (or queried). For example, an action associated with an instant 
messaging address may query an instant messaging system to determine if a corresponding 
user is online or offline. When applications are updated, for example, when a newer version 
of an application is installed or when an application with more advanced functionality is 
installed, a verb association can be changed (e.g., from an association with an existing 
application) such that the verb is associated with the newer or more advanced application. 
[0053] Thus, in some embodiments, contact data can be viewed as being equivalent to a 
task. Accordingly, task execution can be more efficient, since a task can be executed as a 
result of a reduced number of user-entered commands. For example, double-clicking a 
telephone number can be more efficient that navigating a number of menu options to select a 
dial command. 

[0054] A contact data control can have an on object user-interface that hides tasks from 
view until focus is shifted to the contact data control (e.g., by mousing over a field). For 
example, when focus transitions off of a field, the contact data control presents only the 
value contained in the field. However, when focus transitions onto the field, the contact data 
control can present options for manipulating the value contained in the field. 
[0055] Figure 4A illustrates an example of off focus display of contact information 401. 
That is, cursor 402 is not within any of the fields of contact information 401. On the other 
hand, Figure 4B illustrates an example of on focus display of contact information 401. That 
is, cursor 402 is within field 407 causing options 403 to be revealed. Options 403 can 



-Page 18- 



DocketNo. 13768.495 



include options for manipulating (e.g., editing, deleting, performing an action, etc.) the e- 
mail field. 

[0056] A contact data control can utilize a pop-up to edit model that facilitates entering 
of contact data that is subsequently automatically merged to present a simplified view mode. 
Selection of a pop-up option can cause an interface for entering additional contact data to be 
presented. Figure 4C illustrates presentation of interface 41 1 in response to selection of 
pop-up option 409. Selection of an option within interface 411 can cause data fields to be 
presented. For example, selecting "E-mail" can cause an e-mail address field to be 
presented. An e-mail address entered into the field can be automatically merged into the 
contact data 401. Figure 4D illustrates presentation of contact data 401 with a field 408 
containing a merged e-mail address. 

[0057] Thus, contact data controls can provide options for manipulating contact data as a 
result of transitioning focus to a field or as a result of selecting a pop-up option. 
[0058] A contact data controls can intelligently resize interfaces presenting contact data 
based on user-input. For example, portions of an interface can be expanded or collapsed to 
correspondingly present more or less contact data. Resized interfaces can include a "more" 
option that allows collapsed contact data in collapsed positions of an interface to be 
presented. A user can provide input indicating the relative importance of different portions 
of contact data. More important contact data can be included in expanded portions of an 
interface, while less important contact data is accessible through a "more" option in 
collapsed portions of the interface. 

[0059] A contact data control can handle international formatting issues. It may be that 
portions of contact data are represented differently in different locations. For example, the 
contact data included in a postal address can vary from country to country. A contact data 
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control can access external repositories that indicate how contact data is to be presented in 
different locations. For example, the contact data control can access an international address 
repository to determine the ordering of contact data for postal addresses in Russia. 
[0060] A contact data control can allow a user to define how data is presented. Users 
can specify fields that are to be presented, the locations of fields on an interface, the format 
of contact data within a field, etc. For example, a user may specify that telephone numbers 
are to be presented without parenthesis around the area code. When contact data is 
potentially associated with more than one value, a user can specify how many values are to 
be presented. For example, contact data may include six fields (or more) for e-mail address 
values. However, a user may specify that an interface present less than six e-mail addresses 
(e.g., specifying that only a primary e-mail address value be presented). 
[0061] It may be that a user enters presentation preferences into a presentation template 
that defines the user's presentation preferences. A contact data control can access the 
presentation template and present a contact data interface in accordance with the 
presentation template. In some embodiments, a user selects a presentation template from 
among a plurality of pre-defined presentation templates. It may be that presentation 
templates are dynamically updated, for example, when data in an external repository 
changes. For example, a template presenting a postal address in Russia can be updated 
when the postal address format for Russia changes. 

[0062] A contact data control can check for the validity of entered contact data. That is, 
an interface can check with a centralized contact store to validate the format of contact data 
before the contact data is schematized. For example, an interface can validate that telephone 
number field does not contain any letters, such as, for example, A, B, or C. It may be that a 
contact control data validates a format corresponding to specified location. For example, an 
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interface can validate that a United States telephone number included 7 numbers. A contact 
data control can access an international format repository to determine formats for different 
locations. 

[0063] A contact data control can set a default value for a multi-value set. That is, a 
contact data control can cause a value presented in a field to be a default value selected from 
among a plurality of possible values. For example, based on location, a contact data control 
may be configured to default to an area code or zip code value for that location. 
[0064] A contact data control can translate user-entered contact data into schematized 
contact data. A contact control data can invoke a parser to parse user-entered data into 
appropriate data formats of a contact data schema. For example, an invoked parser can 
parse a user-entered string of numbers (e.g., 9998820333) into a formatted area code and 
local telephone number. It should be understood that a storing of number is merely an 
example of user-entered contact data that can be parsed. It would be apparent to one skilled 
in the art, after having reviewed this description, that a wide variety of user-entered data, in 
addition to strings of numbers, can be parsed. 

[0065] Applications can request user-interface data from contact data controls (e.g., 
either a user-interface contact data control or a combined contact data control) to present 
retrieved contact data to a user. For example, application 103 can send user-interface 
request 118 to contact data control 106. In response to user-interface request 118, contact 
data control 106 can return user-interface data 119 to application 103. Application 103 can 
access user-interface data 119 to provide a user-interface for presenting retrieved contact 
data (e.g., contact data retrieved from schematized contact data 108). Returned user- 
interface data can facilitate a user-interface including any of the previous described user- 
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interface functionality. It may be that an application requests and presents a user-interface 
prior to presenting retrieved contact data. 

[0066] Figure 2 illustrates an example flowchart 200 of a method for simplifying 
application access to schematized contact data. The method 200 will be described with 
reference to the modules and data in computer architecture 100. The method 200 includes 
an act of receiving a request to access schematized contact data, the request being received 
at an application that lacks the configuration to natively access the schematized contact data 
(act 201). For example, application 103 may be an application that lacks the configuration 
to natively access schematized contact data 108. Nonetheless, application 102 may receive 
request 112 to access schematized contact data 108. It may that a user of computing system 
101 requests presentation of contact data, such as, for example, contact data 401. 
Accordingly, the user can manipulate an input device (e.g., a mouse or keyboard) to provide 
request 112 to application 103. 

[0067] The method 200 includes an act of calling a contact data control that abstracts the 
formatting of the schematized contact data from the application, the contact data control 
being external to the application (act 202). For example, application 103 can call contact 
data control 106. As previously described, contact data control 106 can be external to 
application 103. Accordingly, other applications, such as, for example, applications 102 and 
104 may also call contact data control 106 (e.g., either a data interface contact data control 
or a combined contact data control) to access schematized contact data. Contact data control 
106 can include any of the previously describe contact data control functionality. 
[0068] In some embodiments, applications may not be authorized to directly access 
schematized contact data. For example, application 103 may not be authorized to directly 
access schematized contact data 108. Thus, the applications may request access to 
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schematized data through an appropriate contact data control. For example, application 103 
may request access to schematized data 108 through contact data control 106. Accordingly, 
contact data control 106 can be designed to provide access only to the portions of 
schematized contact data 108 that are appropriate. Designing contact data controls to have 
limited access to schematized contact data is particularly advantageous in managed code 
environments or other environments where an application's direct access to schematized 
contact data can more easily be controlled. 

[0069] Further, contact data control 106 can abstract the formatting of schematized 
contact data from application 103. Thus, a designer of application 103 need not have 
extensive knowledge of the schema (or schemas) defining formats for schematized contact 
data 108. Simply knowing how to appropriately call contact control data 106 may be 
enough to provide (indirect) access to schematized contact data 108. As previously 
described, contact data control 106 can provide an API that facilitates access to contact data 
control 106. 

[0070] Accordingly, request 112 can be forwarded onto and received at contact data 
control 106. In response to request 112, contact data control 106 can retrieve schematized 
contact data 111 from schematized contact data 108. Contact data control 106 can convert 
schematized contact data 1 1 1 to corresponding non-schematized contact data 109. Contact 
data control 106 can send non-schematized data 109 to application 103. 
[0071] The method 200 includes an act of receiving non-schematized contact data that 
corresponds to the requested schematized contact data (act 203). For example, application 
103 can receive non-schematized data 109. Accordingly, application 103 can present 
contact data (non-schematized contact data 109) notwithstanding that application 103 lacks 
the configuration to access the schematized contact data 108 directly. For example, 

- Page 23 - Docket No. 13768.495 



application 103 can send presentation 114 (e.g., that includes user-interface data 119) to an 
output device, such as, for example, a computer monitor. 

[0072] Applications can request user-interface data from contact data controls (e.g., 
either a user-interface contact data control or a combined contact data control) to present an 
interface for receiving contact data from a user. For example, application 103 can send user- 
interface request 118 to contact data control 106. In response to user-interface request 118, 
contact data control 106 can return user-interface data 119 to application 103. Application 
103 can access user-interface data 119 to provide a user-interface for receiving contact data 
from a user. Returned user-interface data can facilitate a user-interface including any of the 
previous described user-interface functionality. It may be that an application requests and 
presents a user-interface for receiving contact data from a user prior to updating schematized 
contact data. 

[0073] Figure 3 illustrates an example flowchart of a method 300 for simplifying 
application updates to schematized contact data. The method 300 will be described with 
reference to the modules and data in computer architecture 100. The method 300 includes 
an act of receiving non-schematized contact data that is to be included in schematized 
contact data (act 301). The non-schematized contact data can be received at an application 
that lacks the configuration to natively access schematized data. For example, application 
103 can receive request 112. Request 112 can include non-schematized contact data (e.g. 
non-schematized data 109) entered into data fields of application 103. 
[0074] The method 300 includes an act of calling a contact data control that abstracts the 
formatting of the schematized contact data from the application (act 302). For example, 
application 103 can call contact data control 106. As previously described, contact data 
control 106 can be external to application 103. Accordingly, other applications, such as, for 
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example, applications 102 and 104 may also call contact data control 106 to update 
schematized contact data. Calling a contact data control 106 can include sending non- 
schematized contact data 109 to contact data control 106. Contact data control 106 can 
include any of the previously described contact data control functionality. 
[0075] In some embodiments, applications may not be authorized to directly update 
schematized contact data. For example, application 103 may not be authorized to directly 
update schematized contact data 108. Thus, the applications may request access to 
schematized data through an appropriate contact data control. For example, application 103 
may request an update to schematized data 108 through contact data control 106. 
Accordingly, contact data control 106 can be designed to update only the portions of 
schematized contact data 108 that are appropriate. As previously described, limiting access 
is particularly advantageous in managed code environments or other environments where an 
application's direct access to schematized contact data can more easily be controlled. 
[0076] The method 300 includes an act of updating schematized contact data based on 
the non-schematized data (act 303). For example, contact data control 106 can receive non- 
schematized contact data 109. Contact data control 106 can convert non-schematized 
contact data 109 to corresponding schematized contact data 111. Schematized contact data 
111 can conform to contact data schemas that correspond to schematized contact data 108. 
Contact data control 106 can store schematized contact data 111 in schematized contact data 
108. Accordingly, applications that lack the configuration to natively update schematized 
contact data can (indirectly) update schematized contact data through contact data control 
106. Storing schematized contact data 111 in schematized contact data 108 (e.g., a 
centralized data store) can make schematized contact data 111 accessible to other 
applications. 
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[0077] Figure 5 and the following discussion are intended to provide a brief, general 
description of a suitable computing environment in which the invention may be 
implemented. Although not required, the invention will be described in the general context 
of computer-executable instructions, such as program modules, being executed by computer 
systems. Generally, program modules include routines, programs, objects, components, data 
structures, and the like, which perform particular tasks or implement particular abstract data 
types. Computer-executable instructions, associated data structures, and program modules 
represent examples of the program code means for executing acts of the methods disclosed 
herein. 

[0078] With reference to Figure 5, an example system for implementing the invention 
includes a general-purpose computing device in the form of computer system 520, including 
a processing unit 521, a system memory 522, and a system bus 523 that couples various 
system components including the system memory 522 to the processing unit 521. 
Processing unit 521 can execute computer-executable instructions designed to implement 
features of computer system 520, including features of the present invention. The system 
bus 523 may be any of several types of bus structures including a memory bus or memory 
controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The 
system memory includes read only memory ("ROM") 524 and random access memory 
("RAM") 525. A basic input/output system ("BIOS") 526, containing the basic routines that 
help transfer information between elements within computer system 520, such as during 
start-up, may be stored in ROM 524. 

[0079] The computer system 520 may also include magnetic hard disk drive 527 for 
reading from and writing to magnetic hard disk 539, magnetic disk drive 528 for reading 
from or writing to removable magnetic disk 529, and optical disk drive 330 for reading from 
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or writing to removable optical disk 531, such as, or example, a CD-ROM or other optical 
media. The magnetic hard disk drive 527, magnetic disk drive 528, and optical disk drive 
530 are connected to the system bus 523 by hard disk drive interface 532, magnetic disk 
drive-interface 533, and optical drive interface 534, respectively. The drives and their 
associated computer-readable media provide nonvolatile storage of computer-executable 
instructions, data structures, program modules, and other data for the computer system 520. 
Although the example environment described herein employs magnetic hard disk 539, 
removable magnetic disk 529 and removable optical disk 531, other types of computer 
readable media for storing data can be used, including magnetic cassettes, flash memory 
cards, digital versatile disks, Bernoulli cartridges, RAMs, ROMs, and the like. 
[0080] Program code means comprising one or more program modules may be stored on 
hard disk 539, magnetic disk 529, optical disk 531, ROM 524 or RAM 525, including an 
operating system 535, one or more application programs 536* other program modules 537, 
and program data 538. A user may enter commands and information into computer system 
520 through keyboard 540, pointing device 542, or other input devices (not shown), such as, 
for example, a microphone, joy stick, game pad, scanner, or the like. These and other input 
devices can be connected to the processing unit 521 through input/output interface 546 
coupled to system bus 523. Input/output interface 546 logically represents any of a wide 
variety of different interfaces, such as, for example, a serial port interface, a PS/2 interface, a 
parallel port interface, a Universal Serial Bus ("USB") interface, or an Institute of Electrical 
and Electronics Engineers ("IEEE") 1394 interface (i.e., a Fire Wire interface), or may even 
logically represent a combination of different interfaces. 

[0081] A monitor 547 or other display device is also connected to system bus 523 via 
video interface 548. Monitor 547 can display graphical objects, including text, generated by 
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computer system 520. Other peripheral devices (not shown), such as, for example, speakers, 
printers, and scanners, can also be connected to computer system 520. Printers connected to 
computer system 547 can print graphical objects, including text, generated by computer 
system 520. 

[0082] Computer system 520 is connectable to networks, such as, for example, an 
office-wide or enterprise-wide computer network, a home network, an intranet, and/or the 
Internet. Computer system 520 can exchange data with external sources, such as, for 
example, remote computer systems, remote applications, and/or remote databases over such 
networks. 

[0083] Computer system 520 includes network interface 553, through which computer 
system 520 receives data from external sources and/or transmits data to external sources. As 
depicted in Figure 5, network interface 553 facilitates the exchange of data with remote 
computer system 583 via link 551. Network interface 553 can logically represent one or 
more software and/or hardware modules, such as, for example, a network interface card and 
corresponding Network Driver Interface Specification ("NDIS") stack. Link 551 represents 
a portion of a network (e.g., an Ethernet segment), and remote computer system 583 
represents a node of the network. 

[0084] Likewise, computer system 520 includes input/output interface 546, through 
which computer system 520 receives data from external sources and/or transmits data to 
external sources. Input/output interface 546 is coupled to modem 554 (e.g., a standard 
modem, a cable modem, or digital subscriber line ("DSL") modem), through which 
computer system 520 receives data from and/or transmits data to external sources. As 
depicted in Figure 5, input/output interface 546 and modem 554 facilitate the exchange of 
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data with remote computer system 593 via link 552. Link 552 represents a portion of a 
network and remote computer system 593 represents a node of the network. 
[0085] While Figure 5 represents a suitable operating environment for the present 
invention, the principles of the present invention may be employed in any system that is 
capable of, with suitable modification if necessary, implementing the principles of the 
present invention. The environment illustrated in Figure 5 is illustrative only and by no 
means represents even a small portion of the wide variety of environments in which the 
principles of the present invention may be implemented. 

[0086] In accordance with the present invention, applications and contact data controls, 
such as, for example, applications 102-104 and contact data controls 106 and 107, as well as 
associated program data, such as, for example, non-schematized contact data 109, 
schematized contact data 111, and schematized contact data 108, can be stored and accessed 
from any of the computer-readable media associated with computer system 520. For 
example, portions of such modules and portions of associated program data may be included 
in operating system 535, application programs 536, program modules 537 and/or program 
data 538, for storage in system memory 522. 

[0087] When a mass storage device, such as, for example, magnetic hard disk 539, is 
coupled to computer system 520, such modules and associated program data may also be 
stored in the mass storage device. In a networked environment, program modules depicted 
relative to computer system 520, or portions thereof, can be stored in remote memory 
storage devices, such as, system memory and/or mass storage devices associated with 
remote computer system 583 and/or remote computer system 593. Execution of such 
modules may be performed in a distributed environment as previously described. 
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[0088] The present invention may be embodied in other specific forms without departing 
from its spirit or essential characteristics. The described embodiments are to be considered 
in all respects only as illustrative and not restrictive. The scope of the invention is, 
therefore, indicated by the appended claims rather than by the foregoing description. All 
changes, which come within the meaning and range of equivalency of the claims, are to be 
embraced within their scope. 

[0089] What is claimed and desired secured by United States Letters Patent is: 
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